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Applicant or Patentee: Corey Young, et al. Attorneys 
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For: ^Hr^ FOR aHAMWtt ANP 



VERIFIED STATEMENT (DECLARATION) CLAIMING SMALL ENTITY 
STATUS (17 CFR 1.9(f) and i .27 (b)) - INDEPENDENT INVENTOR 

As a below named inventor, 1 hereby declare thai 1 qualify as an independent inventor as defined in 37 CFR 1.9(c) for 
purposes ot paying reduced fees under section A 1(a) and (b) of Title 35, United States Code, to the Patent and Trademark 



the specification filed herewith 

application serial no. filed . 

patent no. • issued " 



I liavc not assigned, granted, conveyed or licensed and am under no obligation under contract or law to assign, grant, 
convey or license, any rights in the invention to any person who could not he classified as an independent inventor under 
37 CFk ] .9(c) ifthatpcrson had made the invention, or to any concern which would not qualify as a small business 
concern under 37 CFR 1 .9(d) or a nonprofit organization under 37 CFR I 9(e). 

Each person, concern or organization to which 1 have assigned, granted, conveyed, or licensed or am under an obligation 
under contract or law to assign, grant, convey, or license any rights in the Invention is listed below: 

I ] rto such person, concern, or organisation 
(x) persons, concents organizations listed below* 

♦NOTE: Separate verified statements arc required from each named person, concern or 
organization having rights to the invention averring to their status as small entities. (37 CFR 1.27) 

FULL NAME MWV PHCTILLC 



ADDRESS 250 Podge Avenue. East Haven. Ct 06512 " 

I ] INDIVIDUAL [x)SMAlXBl>S>Nl^Sa)NCERN [ ] NONPROFIT ORGANIZATION 



FULL NAML 
ADDRESS 



I ) INDIVIDUAL f 1 SMALL BUSINESS CONCERN [] NONPROFIT ORGANIZATION 

I acknowledge the duty to file, in this application or patent, notification of any change In status resulting in loss of 
entitlement to small entity statu) prior to paying, or at the time of paying, the earliest of the issue fee or any maintenance 
foe due after the date on which status as a small entity is no longer appropriate. (11 CFR I -28(b)) 

I hereby declare that ail statements made herein of my own knowledge are true and that alt statements made on 
information and belief are bel ieved lo be true; and further that these statement* were made with the knowledge that 
willful raise statements and the like so made are punishable by fine or imprisonment, or both, under section 1001 of Title 
1 g of the United States Code, and that such wilffiil false statements may jeopardize the validity of the application, any 
patent issuing thereon, or any patent to which this verified statement is directed. 

NAME OF INVENTOR NAME OF INVENTOR NAME Of INVENTOR 
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VERIFIED STATEMENT (DECLARATION) CLAIMING SMALL ENTITY 
STATUS 07 CFR 1 .9(f) end 1,27 (b)) - INDEPENDENT INVENTOR 

As a below named inventor, I hereby declare (hat 1 qualify as an independent inventor u defined in 37 CFR 1.9(c) for 
purposes or paying reduced fees under aeotlon 4 ) (a) and (b) of Title 35, United State* Code, to the Patent and Trademark 
Office with regard 10 the invention entitled ENHANCED HUMAN COMPUTER U^ R INTERFACE SYSTEM FOR 
SEARCHING AND BROWSIN G DOCUMENTS described in 

the specifiwtkHi filed herewith 

application serial no< filed 

] patent no, issued w n 



I have not assigned, panted, conveyed Of licensed end am under no obligation under contract or law lo eesign, grant, 
convey or license, any rights in the invention to any person who could not be olassifled as an independent inventor tmder 
37 CFR L9(c) if that person had made the invention, or to any concern which would not qualify as a small business 
concern under 37 CFR 1 ,9(d) or a nonprofit organization utidur 37 CFR t .9(c), 

Each person, concern or organization to which I have assigned, granted, conveyed, or licensed or am under an obligation 
under contract or iaw to *»slgn, grant, convey* or license any rights in die invention is listed below: 

( 1 no such person, concern, or organization 
(xj persons, concerns organizations listed below* 

♦NOTE: Separate verified statements aw required from each named person, concern or 
organization having rights to the Invention averring to their status as small entitles. (37 CFR L27) 



FULL NAME,. 



ADDRESS 250 Dodge Avenife. Bast Haven. Q 065 12 " 

1 1 INDIVIDUAL [x] SMALL BUSINESS CONCERN [ J NONPROFIT ORGANIZATION 



FULL NAME^ 
ADDRESS 



[ ] INDIVIDUAL (J SMALL BUSINESS CONCERN [ J NONPROFIT ORGANIZATION 

1 acknowledge the duty to file, in this application or patent notification of any change in status resulting in loss of 
entitlement to small entity status prior to paying or at the time of paying, the earliest of the issue fee or any maintenance 
fee due after the date on which status as a wnali entity is no longer appropriate. (37 CFR 1 .28(b)) 

I hereby declare that all statements made herein of my own knowledge are true and that all statements made on 
information and belief are believed to be true; and fUrlher that these statements were made with the knowledge that 
willfiil false statements and the like so made are punishable by fine or imprisonment, or both, under section fOOl of Title 
18 of the United States Code, and that such willful false statements may jeopardize (he validity of the application, any 
patent issuing thereon, or any patent to which this verified statement t* directed. 

Corev Young PtvW KovMWI JraphMftfty _ 

NAME OF INVENTOR NAME OP INVRNTOR J NAME OF INVENTOR 
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VERIFIED STATEMENT (DECLARATION) CLA1MINO SMALL ENTITY STATUS 
(37 CFR 1.9 (f) and 1 .27(c) - SMALL BUSINESS CONCERN 

1 hereby declare that I am 
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the owner of the small business concern identified below: 

on official of the small bcaiaess concern empowered to act oa behtlf of the concetti identified bdevr. 



NAME OF SMALL BUSINESS CONCERN Microliter*, LLC 



ADDRESS OP SMALL BUSINESS CONCERN gODodye Avenue 



I hereby declare that the above identified small business concern qualifies its * sm*li busine$5 concern as defined in 13 
CFR 121,12, and reproduced m 37 CFR \ .9(d), for purposes of paytag reduced foes tn the United States Patent Office 
in that the number of employees of the concern, Including those of its affiliates, does not exceed 500 persons. For 
purposes of this statement, (1) the number of employee* of the busintt* concent u the average over the previous fiscal 
year of the concern of the persons employed on & foil-time, part-time or temporary basis during each ofthe pay periods 
of the fiscal year, and (2) concerns are affiliates of each other when either, directly or indirectly, one concern controls 
or has the power to control the other, or a third party or parties controls or has the power to control both. 

1 hereby declare that rights under contract or law have boen conveyed to and remain with the small business concern 
Identified above with regard to the invention described In; 

the specification Hied herewith with title a* listed above, 
the application identified above, 
the patent identified above. 

if the rights held by the above identified small business concern arc not exclusive, each individual, concern or 
Organization having rights to the invention must file separate verified statements averring to their statu* a* small 
entities, and no rights to the invention are held by any person other than the Inventor, who would not qualify a* an 
Independent inventor under 37 CFR I SHc) if that person made the invention* or by any concern which would not 
quality as a small business concern under 37 CFR J or a nonprofit organization undwr 37 CFR 1.9(c). 

Each person concern or organization having any ritftts in the invention h listed below: 
[ .] no such person concern or organization exists, 
[x] each such person concern or organization i9 Hated below. 

Separate verified statements arc required from each named person concern or organization having rights to the 
invention averring to their status as small entities (37 CFR 1 27) 

I acknowledge the duty to file, in ihk application or patent, notification of any change in status resulting In loss of 
cntrriemenl Ui small entity status prior to paying, or at the time of paving, the earliest of the issue fix or any 
maintenance fee due after the date on which status as a small entity is no longer appropriate. (37 CFR 1 38(b)) 

1 hereby declare that all statements made herein of my own knowledge are tme and that all statements made on 
information and belief axe believed to be true; and farther that these statements were made with the knowledge that 
willful falsa statements and the like w> made are punishable by fine or imprisonment, or both, under section 1001 of 
Title i 8 of the United States Code, and that such willful false statements may jeopardize the validity of the application, 
any patent issuing thereon, or any patent to which this verified statement is directed 
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IK THE UNITED STATES PATENT AND TRADEMARK- OFFICE 
Applicant(s): Young, etal. 
Serial No.: 
Filed: 

For: ENHANCED HUMAN COMPUTER USER INTERFACE SYSTEM FOR 

SEARCHING AND BROWSING DOCUMENTS 



October 18, 2000 

Hon. Commissioner of Patents and 

Trademarks 
Washington, DC 20231 

Sir: 

PRFXJMMARYrAMENTJMEJ^T 
Prior to examination on the merits, please amend the application as follows: 

IN THE SPECIFICATION 

Please insert on page 1, before line 1, —The present application claims priority from 

Provisional Patent Application Serial No. 60/160,243 filed on October 18, 1999.-- 

IN THE CLAIMS 

Please cancel claims 1-3. 

Please add new claims 5-18 as follows: 

—5. A method for presenting document records to a user through a display interface, 
comprising the steps of: 

-1- 



(a) managing a plurality of data files with a host application, the host application 
supporting applet execution; 

(b) selecting a data file from a plurality of data files; 

(c) analyzing the data file for the presence of data of a first type and a second type; 

(d) processing data of the first type through a first applet and data of the second type 
through a second applet; 

(e) merging and formatting the processed first and second data within the host 
application; and 

(f) displaying the merged and formatted processed first and second data. 

6. The method according to claim 5, wherein the first data type is a graphics type 
and a second data type is a text data type. 

7. The method according to claim 5, wherein the data file comprises a tagged format. 

8. The method according to claim 5, wherein the first data type comprises a 
compressed format image. 

9. The method according to claim 5, wherein the data file comprises: 
a header portion containing an index portion; 

a first data type located near a terminus of the data file at a starting location referenced by 
the index portion; and 

-2- 



a second data type located between the header and the first data type, having an end of 
file marker at its terminus. 



10. The method according to claim 5, wherein the host application comprises a 
hypertext browser. 

11. A data file format comprising: 

a header portion containing an index portion; 

a first data type located near a terminus of the data file at a starting location referenced by 
the index portion; and 

a second data type located between the header arid the first data type, having an end of 
file marker at its terminus. 

12. The data file format according to claim 11, wherein said data file format is 
compatible with the Group-4 Tagged Image Format File (TIFF) specifications, said first data 
type corresponding to compressed image data. 

13. The data file format according to claim 11, wherein said second data type 
comprises a text file contextually associated with said first data type. 

A method of processing a data file having two different data types, comprising the 



14. 

steps of: 
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(a) processing the data file with a first applet, adapted for reading data of a first data 
type, to extract data of the first data type; 

(b) processing the data file with a second applet, adapted for reading data of a second 
data type, to extract data of the second data type, 

wherein the data file includes an index portion in a header pointing to the first data type, 
and the second data type resides between the header and the first data type, having an end of file 
marker at a terminus thereof. 

15. The method according to claim 14, wherein the first applet skips past the end of 
file market based on the index portion, thereby circumventing processing of the second data type. 

16. The method according to claim 14, wherein an object browser accesses the data 
file, and invokes the first and second applets for interpreting the composite data. 

17. The method according to claim 14; wherein the first data type is a graphics type 
and a second data type is a text data type. 

18. The method according to claim 14, wherein the header and first data type are 
compatible with the Group 4 Tagged Image Format File specifications. - 

REMARKS 

Claims 3-18 are in the application. Claims 1-3 have been replaced with claims 5-18. 

-4- 



An early action on the merits is respectfully solicited. 



Respectfully submitted 




Steven M. Hoffber; 
Reg. No. 33,511 
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Enhanced Human Computer User Interface 
System For Searching and Browsing Documents 

5 Field op the Invention 

The present invention relates to the field of improved document browsers, and more particularly 
to an improved human computer user interface system and method for searching, browsing and 
selecting documents stored in a massive database having a relatively consistent format including 
graphics, defined fields, and large variable sized text object portions. The present invention also 

10 relates to the field of data file structures, and more particularly to data files combining both text 
and graphics. 



Background of the Invention 
15 It is well known in the art to provide graphic interfaces for analyzing database search results. 
Further, browser systems are known which format and display both text and graphics. For 
example, the Folio Infoba.se system. Jouve S.A. GTI, and Dataware engines, as well as 
commercially deployed systems from Lexis/Nexis, Westlaw, MicroPatent LLC (assignee 
hereof), as well as many other proprietary and Internet based systems, provide such capabilities. 

20 

Typically, the graphic content of such documents is small or insignificant in comparison to the 
text, or the text and graphics are stored as separate file types. Systems that store text and 
compressed graphics in a single file, with user defined and/or intelligent control over display 
formatting at the client are not generally found. 

25 
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It is well known in the art to provide graphic interfaces for analyzing database search results. 
Further, browser systems are known which format and display both text and graphics. For 
example, the Folio Infobase system. Jouve S.A. GTL and Dataware engines, as well as 
commercially deployed systems from Lexis/Nexis, Wesilaw, MicroPatent LLC (assignee 
5 hereof), as well as many other proprietary and Internet based systems, provide such capabilities. 

Typically, the graphic content of such documents is small or insignificant in comparison to the 
text, or the text and graphics are stored as separate file types. Systems that store text and 
compressed graphics in a single file, with user defined and/or intelligent control over display 
10 formatting at the client are not generally found. 

It is also known to allow selection of a group of listed documents for later processing. However, 
the prior art typically does not allow the user to classify listed documents into a plurality of 
different classifications for selective processing according to the categorization. 

15 

It is well known in the art to provide data files having text and graphic data content. For 
example, popular word processing formats, Adobe PDF®, and other file types integrate text and 
graphics. 

20 These formats, however, are proprietary, meaning that other software packages are typically 
unable to process types of data stored in the files. Thus, the data embedded in such composite 
data files is typically unavailable or partially unavailable to thin applets designed to deal with 
various standard data formats. 
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One alternative is to provide the data in two separate files, leading to certain difficulties in 
maintaining the relation between the two portions of the file. Likewise, a wrapper may be 
provided to encompass the pair of files in a single resulting file, such as by using the known ZIP 
format. However, this entails use of an additional applet. 
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Summary and Objects of the Invention 
The present invention provides a system and method for receiving a set of files, each potentially 
including text and compressed graphics, reading the text portion including embedded tags, 
decoding the graphic portion, and displaying the text and graphics on a computer screen in 
5 accordance with user preferences. 

This is accomplished by providing index pointers within the file to identify the start of the 
compressed graphic with respect to the beginning of the file, thereby permitting text data to be 
placed before the designated offset. This arrangement is compatible with the known Group-4 
10 compressed tagged image format file (TIFF) file. Thus, a known TIFF graphic processing 
module can directly operate on the file without modification. 

The index pointer resides at the beginning of the file; therefore, a standard-type text processing 
tool can easily process these files without substantial manipulation. Thus, both text and 
15 compressed graphic can be directly extracted from a single file using separate application 
modules without physical parsing or duplication. 

The text may be further indexed to provide further functions, such as selectable sections, text 
searching, or other known functions. According to a preferred embodiment, the text is divided 
20 into paragraphs, wherein selected paragraphs are addressable by tag. A user selectable tab 
corresponds to the address tag, facilitating navigation through the text. 
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The preferred embodiment also preferably provides an intelligent display formatter to control the 
display of the text in conjunction with the image. Based on the size of the image, the width 
and/or height of the displayed text are controlled. Further, the scaling of displayed images may 
also be controlled. 

5 

The user interface is controlled by a host application, which also functions to manage a plurality 
of data files, for example providing a list for the user to select from, and allowing the user to sort 
and subselect from the list. 

10 The present invention provides a system and method for receiving a set of records, displaying the 
contents of the record, including e.g., text and graphics, on a computer screen, and allowing the 
user to categorize the records into at least three classes for later selective processing. 

This is accomplished by providing a record list on a graphic user interface, in which each record 
15 on the list may be individually selected, providing at least two categorization inputs from the 
user, providing an indicia in the record list to indicate a respective record classification, and 
providing means for selectively processing the records according to a respective classification 
thereof. 

20 The present invention also provides a data file system and method, the data file potentially 
including text and compressed graphics, which can be read by applets which; are capable of 
reading standard file types. Essentially, the file format includes an offset pointer at a 
predetermined location, such as in the header of the file, which points to a first data type. The 
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first data type is found in a latter portion of the file, The second data type resides after the 
header, and before the first data type, and ends with an end-of-file (EOF) marker. Therefore, the 
file may be read by a standard reader for the first data type* while the file may also be read by a 
reader for the second data type, possibly with an offset to avoid inclusion of the header 
5 information including the data pointer. 

Thus, index pointers within the file identify the start of the compressed graphic with respect to 
the beginning of the file, thereby permitting text data to be placed before the designated offset. 
For example, the file type is a standard TIFF format, with the first data type being Group-4 
10 compressed image and the second data type being ACSII or formatted text, {See, Adobe 
Corporation, TIFF 6.0 specification). 

The index pointer resides at the beginning of the file; therefore, a standard-type text processing 
tool can easily process these files without substantial manipulation. Thus, both text and 
15 compressed graphic can be directly extracted from a single file using separate application 
modules without physical parsing or duplication. 

The readers for the first and second data types may be controlled by a host application, which 
may also functions to manage a plurality of data files, for example providing a list for the user to 
20 select from, and allowing the user to sort and subselect from the list. 
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TIFF is an image file format. The largest possible TIFF file is 2 J2 bytes in length. A TIFF file 
begins with an 8-byte image file header that points to an image file directory (IFD). An image 
file directory contains information about the image, as well as pointers to the actual image data. 

5 The TIFF specification provides for private fields and values. An organization might wish to 
store information meaningful to only that organization in a TIFF file. Tags numbered 32768 or 
higher, sometimes called private tags, are reserved for that purpose, and may be registered for 
exclusive use. TIFF tags in the "reusable" 65000-65535 range are available for use without 
registration, and are especially useful for closed environments. These tags, however, are not 

10 intended to facilitate a large data storage area within the TIFF file for storage of non-image data 
intended to be read by an application designed for a different file type. 

The TIFF specification anticipates that new TIFF field types will appear. Therefore, one design 
criterion for readers is that they should skip over fields containing an unexpected field type. 
15 Each TIFF field has an associated Count. This means that all fields are actually one-dimensional 
arrays, even though most fields contain only a single value. For example, to store a complicated 
data structure in a single private field, an "undefined" type is established and the Count set to the 
number of bytes required to hold the data structure. 

20 The Tagged Image File Format has a header which is defined as follows: 
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[ Offset" [ Length '• Description 

2 Bvte Order: MM or II > 

j 

2 "Version Number", this is always 42 for TIFF images ; 

i 

4 Pointer to the first IFD j 

I 

. i 

The byte order refers to the endian used in the file, and is a two-letter ACSil record being either 
MM or II (4D4D hex or 4949 hex) referring to Motorola or Intel architecture. The version 
5 number 42 identifies the file as being a TIFF file. The IFD pointer is a 4 bytes value that is an 
offset from the start of the file and points to the first IFD that are explained below. Objects 
within the file are typically referenced with pointers. 

Within the image file, directories are defined in the following manner: 

10 

Offset Le ngth Description 

6 2 Entry Count 

"~T 12"™"! Entry!) j 

14 12 Entry 1 

I 

n* 12+2 '"if Entry n j 

n*12+4 4 Pointer to subsequent IFD or 0000 j 

These directory entries are 12 byte data records that store the relevant specifications on the 
image stored. The size, compression, colors used, a table of pointers showing the raster data 
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location and other parameters of the image. Before the 1FD proper, a 2-byte value is provided 
indicating the number of IFD's present in the file. Then the IFD's are consecutively provided 
after the count. 



5 Each IFD entry is formatted as follows: 

Offset Length Description 
"02 Tag 

2 ' 2 Type of Data 

; "4 : 4 Count Field 

8 4 Data Pointer or Data Field 

The first two bytes are a tag. identifying what the directory entry is about. The "Data Type" 
indicates the type of the data stored in this entry. The Count field specifies the number of values 
stored and not the number of bytes stored. The final 4 bytes store either a pointer to the location 
10 of the data, or, if the data can fit in 4 bytes, then the data itself is here. 



It is therefore an object of the invention to provide a system and method for manipulating a 
record list, in which each record on the list may be individually selected, providing at least two 
distinct categorization inputs from the user, providing an indicia in the record list to indicate a 
15 respective record classification, and providing means for selectively processing the records 
according to a respective classification thereof. 

It is also an object of the invention to provide a system and method for extracting data of a first 
type and a second type from a single file, comprising processing data of the first type through a 
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first applet and data of the second type through a second applet the file inherently designates 
separate data storage regions. 

It is a further object of the invention to provide a system and method for presenting document 
5 records to a user through a display interface, comprising the steps of analyzing a data file for the 
presence of data of a first type and a second type, processing data of the first type through a first 
applet and data of the second type through a second applet, merging and formatting the 
processed first and second data with a host application, displaying the merged and formatted 
processed first and second data. 

10 

These and other objects will become apparent from a review of the drawings and detailed 
description of the invention. 



Kovanen et al. 



-10- 



( 

Brief Description of the Drawings 

The invention will now be described wilh reference to the accompanying drawings, in 

which: 

Fig. 1 is a schematic block diagram of a known image file; 

Fig. 2 is a schematic block diagram of composite image and text file; 

Fig. 3 is a diagram showing structured, fielded format of records and fields; 

Fig. 4 is a view showing a graphic user interface screen layout with a left-side graphic 
according to a preferred embodiment: 

Fig. 5 is a logical flow chart showing a screen format decision process; 

Fig. 6 is a view showing a graphic user interface screen layout with a top side graphic 
according to a preferred embodiment; 

Fig. 7 is a view of a dialog box for receiving user display format preferences: 

Figs. 8 and 9 are two display screens of a preferred embodiment respectively before and 
after a PictureBox has been moved; 

Fig. 10 shows a display screen of a preferred embodiment where the width of an image 
doesn't fill the horizontal space provided by the maximum percentage area setting; 

Figs. 11 and 12 show display screens of a preferred embodiment with two different total 
display area sizes, wide and tall, respectively; 

Fig. 13 shows a logical flow chart of the general process for positioning and sizing the 

controls; 

Fig. 14 shows a logical flow chart that calculates the image size and orientation with 
relation to a text portion; 
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Fig. 15 shows a logical flow chart for automatically scrolling the text to a section 
corresponding to a user-selected section tab; 

Fig, 16 shows a logical How chart for automatically selecting the tab that corresponds to 
the section that is currently visible on the display; and 
5 Fig. 17 shows a flow chart illustrating the detailed steps needed to calculate the image 

and text control coverage areas; 

Figs. 18 and 19 show display screens of a preferred embodiment while viewing two 
different sections of text; and 

Fig. 20 shows a list of patents with selections and exclusions. 
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Description of the Preferred Embodiment 
The foregoing and other objects, features and advantages of the present invention will become 
more readily apparent to those skilled in the art to which the invention pertains upon reference to 
the following detailed description of one of the best modes for carrying out the invention, when 
5 considered in conjunction with the accompanying drawing in which preferred embodiments of 
the invention are shown and described by way of illustration, and not of limitation, wherein: 

A preferred embodiment of the present invention provides a system and method for displaying a 
summary document from a document record on a graphic user interface (GUI) system. In 
10 general, the documents may be of a variety of types, however it is particularly preferred that they 
consist of a collection patents, defined by a collection criterion from the fullest of patent 
documents, As discussed below, the document file may have a particular format, and include 
image as well as text information. 

1 5 Operating System and Tools 

The present invention may be implemented in any suitable GUI-enabled operating system, such 
as Windows®. For purposes of illustrating the preferred embodiment, a solution using 
Windows® and Visual Basic® Professional 3.0 will be described. 

20 File Format 

The file format containing the information to be displayed is also arbitrary. For purposes of 
illustrating the preferred embodiment, a Group-4 compressed TIFF image file will be used. 
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The TIFF specification allows for modifications to the image header to accommodate additional 
proprietary data. Because the preferred embodiment displays summary document information 
consisting of an image, text, or both, the TIFF specification lends itself well to the 
implementation of the preferred embodiment. 

5 

Figure 1 illustrates the typical layout of a TIFF file. The file starts with an Image File Header 
101 that identifies it as being a TIFF file. The Image File Header also serves as a pointer to an 
Image File Directory 102. which contains information about the image as well as a pointer to the 
actual Image Data 103. 

S° 

5 Figure 2 illustrates the layout of a modified TIFF file utilized by the preferred embodiment, 
j which contains certain non-image ASCII text (Text) 104. The method for embedding the Text 

within the TIFF file is to rewrite the file, writing first the Image File Header, then writing the 
3 Text, then writing the Image File Directory and the Image Data. It is important to note that an 
Jl 5 End of File (EOF) character terminates the Text portion. This allows the preferred embodiment 
" to use a standard text file loading procedure when loading the Text into memory. Thus, available 

text reader software typically ignores data after the EOF character. 

The format of the Text may be a standard or proprietary format, preferably proprietary in the 
20 preferred embodiment. The preferred format consists of a structured, fielded format of records 
and fields as illustrated in Figure 3. A record of the text file is considered to be a series of ASCII 
characters 301 followed by a CR (ASCII 13) character 302. then a LF (ASCII 10) character 303. 
A record contains one or more fields. Fields 304 are a series of ASCII characters delimited by a 
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tab (ASCII 9) character 305. The first field 306 of a record is the record type. This is typically a 
word that best describes the piece of data contained in the record. For example. Figure 3 shows a 
record of type Description and of type Claim. 

The remainder of the fields are typically referred to as the record text 207. There may be 
multiple fields contained in the record text. However, it is only important to note that there is a 
distinct first field that is the record type, and each additional field of the record thereafter is a 
part of the record text 207. 

As noted above, the Text portion, e.g.. the end of the record text 207. terminates with an EOF 
character, before the image data begins. 

Windows Common Controls 
The preferred embodiment utilizes a plurality of Windows® Visual Basic® (VBX) controls. A 
VBX control is a third party product that provides specific functionality to the utilizing 
application. The benefit of using VBX controls is that it simplifies the implementation of the 
preferred embodiment because the needed functionality is already developed by a third party 
company and encapsulated into the VBX controls. 

VBX controls provide functionality using a common programming interface. Specifically, VBX 
controls provide Methods, Events, and Propeuies. 
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Methods are subroutines or functions utilized by the programmer that operate on the VBX 
controls. 

Events are actions, such as clicking the mouse or pressing a key, and for which the programmer 
5 can write code to respond. Events can occur as a result of user action or program code, or they 
can be triggered by the graphic user interface (GUI) system. 

Properties are named attributes of VBX controls. Properties define the VBX control's 
characteristics (such as size, color, screen location, etc.) or VBX control behaviors (whether it is 

10 enabled or visible, etc.). Most VBX controls provide a set of similar Properties for manipulating 
features common to each of the controls. Properties of the VBX controls that are used heavily by 
the preferred embodiment in the visual display of the summary document information are Top, 
Left, Height, Width, and Visible, These Properties define the top and left positioning of the 
control relative to the top of the program's window, the width and height of the control, and 

15 whether or not the control is visible lo the user. 

Some VBX controls are "encapsulating" controls. That is, they allow the program designer to 
place other VBX controls on top of them. In this case, the VBX controls placed on top of an 
encapsulating control then become a child of that control. 

20 

The VBX controls used in the implementation of the preferred embodiment will now be 
described in more detail. 
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For implementing the loading and display of the document image, which as discussed above is 
stored in the Group-4 compressed TIFF format, the Accusoft ImageGEAR (Gear) product is 
used. Gear is a VBX control that provides image display and manipulation functionality. Table 
1 lists the Properties of Gear that were changed from their defaults at design time, in the 
implementation of the preferred embodiment. (The other initial properties remain unchanged). 



Table 1 - Initial Properties of Gear 

BorderStyle ^ 0 - None 

DisplayStretch = True 

Name - ItngDocutnent 

Visible = False 



For implementing the display of the document text embedded in the TIFF file, the BennetTec 
AllText (AUTexO product is used. AUText is a VBX control that provides functionality for the 
display of text in a formatted manner similar to that of the Microsoft Rich Text specification. 
Table 2 lists the Properties of AllText that were changed from their defaults at design time, in the 
implementation of the preferred embodiment. 



Table 2 - Initial Properties of AllText 



BorderStyle 
DropFileMode 
F30N 

MouseHPomter 
Name 
ScrollBarH 



= 0 - None 
= 1 - Crop Event 
- False 
-13- ringer 
= AtxDocument 
l - Invisible 



For implementing the tab strip located below the display area, the FarPoint Tab Pro (TabPro) 
product is used. TabPro is a Windows® VBX control that provides functionality for a tab strip 
similar to the tabs as can be seen on a Property page dialog in Windows®. Table 3 lists the 
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Properties of TabPro that were changed from their defaults at design time, in the implementation 
of the preferred embodiment. 



Table 3 - Initial Properties of TabPro 



Act iveTabBcld 
AllignTVx'tH 
All igr. Text'.' 
AllowSeroll 
10 DrawFocu s Rect 

Fcr.tEoid 
Margin Left 
MargmRight 
Name 

15 Orientation 
TabCaption 



TabHeight 

20 TabSeparator 

TabShape 
TabStop 
ThreeDInnerWidth 
ThreeDInnerWidthAct lve 
25 Visible 



raise 

1 * Center 

l - Center 

1 - Scroll (Show Whole) 

1 - No 
False 
150 
150 

TbsDocument 

2 - Bottom 

Abstract , Bibliographic , References , 

Cited By, Summary, Drawings, Description, 
Exemplary , Claims , Notes 

220 

-12 

1 - Slanted 

False 

0 

0 

False 



The TabCaption Properly is unique in that its value depends on which tab on TabPro is selected 
at design time. Thus, the TabCaption Property may have several values at once. Because of this, 
in Table 3 all of the values used for the sample application utilizing the preferred embodiment 

30 are listed for the TabCaption Property. Also note that the TabCaption property for a particular 
tab can be set at runtime as well. The Tab Property provides an interface to specify which tab's 
Properties are to be changed. Thus, if a programmer at runtime wanted the TabCaption property 
changed for the third Tab, they would first set the Tab Property to three, then set the TabCaption 
properly to the new value. Thus, the functionality of the system may be altered through a set-up 

35 routine run after distribution of the software. 
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Another VBX control may be used for implementing the encapsulating 3D frame (Panel) around 
the display area. Panel provides no real functionality to the preferred embodiment other than to 
serve both as a frame thai encapsulates the other VBX controls used for the display of the 
summary document information, and as a cosmetic enhancement. Table 4 lists the properties of 
5 the Panel control that were changed from their defaults at design time, in the implementation of 
the preferred embodiment. 



Table 4 - Initial Properties of Panel 

10 BevelOuter = 1 - Inset 

Caption = <Null> 

FontBold = False 

FontSize = 24 

Name - PnDccurnent 

15 Visible - False 



For implementing the sliding carrots located above and to the left of the display area, the 
Microsoft Picture Box (PictureBox) VBX control included with Visual Basic™ Professional 3.0 
is used. A pre-created bitmap is loaded into this control at design time giving the control the 
20 appearance of being a small carrot. Table 5 lists the properties of PictureBox that were changed 
from their defaults at design time, in the implementation of the preferred embodiment. 



Table 5 - Initial Properties of PictureBox 

25 AutoSize = Trup 

BackColoi ~ &H00C:C0C0*< 

BorderStyle = 0 - None 

Name ^ Spl i t terVert ical , Spl it terHor izont ai 

Visible = False 

30 



Because there are two PictureBox controls utilized in the preferred embodiment (one for each 
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carrot), two values for the Name property have been listed in Table 5. Each value corresponds to 
the instance of the PictureBox control to which it relates. 

Host Application 

5 The preferred embodiment is not of itself an application program. The preferred embodiment 
represents software-defined functionality that can be utilized by an application program. Thus, 
hereafter the application program utilizing the preferred embodiment will be referred to as the 
host application (Host). Figure 4 provides a display screen of the host application. 

10 The Host must provide a portion of its display window to the preferred embodiment. This is a 
rectangular area 401 that the preferred embodiment utilizes for the display of the summary 
document information. This provided area may or may not be sizeable. In the particular Host 
presented, the area provided to the preferred embodiment is sized in dependence on how the user 
sizes the Host window. 

15 

The area provided is made up of the previously defined VBX controls. Specifically, the Panel 
control 402 is used to cover the entire area provided. More specifically, the Panel control's Left 
and Top properties are defined as always being set to the left 403 and top 404 positions of the 
area provided. The Width and Height properties are defined as always being set to the width 405 
20 and height 406 of the area provided. The encapsulated area provided by the Panel control 401 
will hereafter be referred to as the total display area (TDA) utilized by the preferred embodiment 
for the display of the summary document information. 
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Encapsulated in the TDA are one instance of the Gear 407. AllText 408, and TabPro 409 VBX 
controls, and two instances 410a (Figure 4) and 410b (Figure 6) of the PictureBox VBX control 
(one for each carrot). It is important to note that when referring to the Top, Left. Height, and 
Width properties of these controls, or when referring to values associated with calculating the 
5 positioning of these controls within the encapsulated Panel, the Properties and values are relative 
to the Panel and not the application window. 

Hereafter the term Gear will be used when referring to the document image display area or 
anything related to it. 

;|o 

'P, Hereafter the term AllText will be used when referring to the document text display area or 
Q anything related to it. 

Q Hereafter a carrot will be referred to as a PictureBox. When describing the functionality of a 
■S| 5 carrot, it will be in terms of the horizontal carrot 410. However, the functionality disclosed 
U serves as the functionality used for implementing both carrots, although the orientation (vertical 

or horizontal) of each carrot is different and thus certain properties and values may be different 

in actual practice as anyone skilled in the art will recognize. 

20 The method for choosing a document to be loaded into the preferred embodiment is arbitrary. 
The Host provides a list of documents 41 1 from which the user can select. When a document is 
selected 412. such as by clicking or double-clicking (i.e., generating an appropriate event in 
association with the document) with the GUI pointing device, the preferred embodiment loads it. 
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Displaying Document Summary Information 
The general process for displaying the summary document information is outlined in the 
flowchart in Figure 5. 

5 

Step 501 loads the text portion of the document specified by the Host into memory. The process 
of extracting the text from the TIFF file is a straightforward one and recognizable by one skilled 
in the art. However, it is important to note that the Image File Header 101 must be skipped, i.e., 
is not intended to be displayed as text. The easiest way to do this is to move the file pointer to 

10 byte position 1 1 in the file, because the Image File Header is always 10 bytes long. Once the file 
pointer has been positioned at byte 11. the file can be loaded and stored into memory using a 
known common text file loading procedure, noting the existence of an EOF character at the end 
of the Text and just before the image data. In the same manner, multiple text files may be 
addressed by noting their offset from the first byte of the file and initializing the file pointer 

15 appropriately. In this case, an EOF is provided after each text segment. All text segments 
preferably precede the compressed image data. Where the file organization is complex, the first 
record starting at byte 1 1 may be an index, with pointers (and possibly descriptive information) 
stored defining the respective offsets. Managing this index and multiple text records, of course, 
requires additional logic, which is not further described herein, but impiementable without the 

20 exercise of undue experimentation by one of ordinary skill in the art. This record management 
scheme may be implemented as a VBX control or within the Host. 
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It is also noted that, in the event of sequential records (as opposed to randomly accessible 
records), the existence and/or nature of a subsequent record may be defined within each Text 
portion, thus eliminating the need for the above-described index, 

5 The Text is loaded first because it contains additional information helpful to the preferred 
embodiment in determining if an image is available. More specifically, there exists a record of 
type Cropped that defines whether or not an image is available. If the Cropped record text 
contains "Yes" then there exists an image. If it contains "No" then there does not exist an image. 
Note that the Cropped record is ignored when determining if text information is available. 

10 Therefore, the present preferred embodiment provides a common TIFF format file that 
potentially contains no image information. While TIFF is generally intended for image data, the 
format provides sufficient flexibility for use as a text file format. 

Step 502 checks to see if there exists text information for the document. If no text information in 
15 addition to the Cropped record was loaded from the document in Step 501, then the preferred 
embodiment moves to Step 503. Otherwise, the preferred embodiment moves to Step 505. 

Steps 503 checks to see if there exists an image for the document by checking the Cropped 
record text contents as previously described. If an image does exist, the preferred embodiment 
20 moves to Step 504. Otherwise, the preferred embodiment does not display any document 
information, as non^ is available. 
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Records which do not contain any document information, while seemingly useless in the 
preferred embodiment, may still have utility, since they may contain other data types, including 
executable code, accounting information, e-mail, etc. which may be handled by the host outside 
of the preferred embodiment of the human user computer interface. Advantageously, the system 
5 employs a single file type, TIFF, for communication with the Host. Of course, the Host need not 
be limited to reading or manipulating this file format. 

Step 504 displays only an image. To do this, the preferred embodiment sets AHText's Visible 
Property to False and sets Gear's Width and Height Properties to the width and height of the 

CilO TDA, respectively. This has the effect of utilizing the entire TDA for the display of the image. 

l p The image is loaded into the Gear control using the Loadlmage Property of the control. 

^ Step 505 checks to see if there exists an image for the document by checking the cropped record 
□ text contents as previously described. If an image does exist, the preferred embodiment moves 
Wl5 to Step 508. Otherwise, the preferred embodiment moves to Step 506. 

Step 506 checks to see if there exists text information for the document. If no text information in 
addition to the Cropped record was loaded for the document in Step 501, then the preferred 
embodiment does not display any document information, as none is available* Otherwise, the 
20 preferred embodiment moves to Step 507. 

Step 507 displays only the text. To do this, the preferred embodiment sets Gear's Visible 
Property to False and sets AHText's Width and Height Properties to the width and height of the 
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TDA, respectively. This has the effect of utilizing the entire TDA for the display of the text. 
The text is loaded into AIIText by the Host. 



Step 508 calculates and positions the VBX controls on the TDA. The process for doing this is 
5 shown in the flowchart of Figure 13 and will be explained in detail later herein. 

Step 509 loads the image into Gear and. the text into AIIText using the same methods as 
described in Steps 504 and 507, with the one exception that Gear and AIIText do not fill the 
entire area as described, but instead remain in their positions as determined by Step 508. The 
10 Visible Property of Gear and AIIText is set to True. 

User Specified Settings 
The user-specified settings are maintained using internal variables specific to the preferred 
embodiment. An internal variable is a term recognized by those skilled in the art. Table 6 shows 
15 the internal variable names used and their corresponding purposes. Note that these variable 
names will be used throughout the remainder of the description of the preferred embodiment for 
equations and illustrative purposes. 



Table 6 - Internal Variables for User-Specified Settings 

20 

ImageFositicn 

The position of the document image in relation to the 
text. This is a mutually exclusive setting with the 
value oemg one of the three possible constant 
25 values: 



ImagePcsitio.oAuto 

Specifies- that the image position in relation to the 
text should be auto-calculated based on the image 
30 width and height and the TDA width and height. 
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ImagePositionAbove 

Specifies that the image should be positioned above 
the text. 

IrnagePcsi t: :onLer t 

Specifies that the image should be positioned to the 

left <:f th<_- t-xt. 

S\A it t eiTosVer ti : U 

The ruix:::,'^ TT-A ^pace the drawing is allowed to 
occupy when positioned above the text. This is a 
value" that is a percentage of the TDA height and is 
clamped to the rang* MO, SO] .e.g., 20 would be 20%) 
where iht" i ar.ge is an integer value. 

Spli t tet PosHorizontal 

The maxir.-tt TDA space the drawing is allowed to 
occupy when positioned to the left of the text. This 
is a value that is a percentage of the TDA width and 
is clamped to the range [10, 50] (e.g., 20 would be 
20%) where the range is an integer value. 



The preferred embodiment allows the user to explicitly specify whether they want the document 
image oriented above the text as illustrated in Figure 6. to the left of the text as illustrated in 
Figure 4, or whether the document image orientation should be auto-calculated. This user- 
specified setting will be referred to as the Orientation setting hereafter and is defined by the 
variable ImagePosition described in Table 6. In addition, when referring to the orientation of the 
image hereafter, it is to be assumed to be in relation to the text {above the text or to the left of the 
text). 

When the Orientation setting is set to auto-calculate, the preferred embodiment orients the image 
based on the TDA height 405 and width 406, image height and width, and a setting to be 
described later that defines the maximum percentage of area 413 of the TDA the image is 
allowed to use. The auto-calculation setting allows the preferred embodiment to find an optimal 
orientation for the image (e.g., display the image to the left of the text in the case where the Host 
window is sized to be very wide). This allows the user to see as much information as possible. 
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The preferred embodiment allows the user to specify the maximum percentage of area of the 
TDA the image is allowed to use. Because there are two possible orientations for the image as 
illustrated in Figures 6 and 4, the user is allowed to specify this percentage separately for each 
5 orientation as defined by the variables SplitterPos Vertical and SpIitterPosHorizontal as described 
in Table 6. These two settings will be referred to as Maximum Percentage settings hereafter, 

The Host allows the user to specify these settings using a settings dialog. Figure 7 shows a 
display screen of the settings dialog. Here it can be seen that ImageOrientation can be set using 

10 701, SplitterPos Vertical by 702, and SpIitterPosHorizontal by 703. When the user presses the 
OK button 704. the setting values specified by the user in the dialog are recorded into the internal 
variables shown in Table 6. The values of the settings may be stored in non-volatile memory, 
such in a file on a computer hard disk. This can be done using any generalized saving method 
understood by anyone educated in the an. These values may be stored, for example, in a so- 

15 called ".INI" file. 

The preferred embodiment also inherently provides the ability to change the SplitterPosVertical 
and SpIitterPosHorizontal settings using the two carrots located on the top and left edges of the 
TDA. The carrots are implemented using the PictureBox control. As previously described, in 
20 the preferred embodiment a pre-created bitmap is loaded into PictureBox at application design 
time. This provides the visual appearance of the carrot* 
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The preferred embodiment allows the user to move PictureBox using the GUI mouse interface 
mechanism. As previously described, a typical GUI provides feedback to an application in the 
form of an Event whenever the user performs different actions using the various input devices, 
such as a mouse. The Events that the preferred embodiment traps for PictureBox manipulation 
are defined in Table 7. 

Table 7 - Events Trapped by the Preferred Embodiment 
for Manipulating the PictureBoxos 

MouseDown - The event sent by the GUI when the mouse button is pressed 
by the user. 

MouseMove - The event sent by the GUI when the mouse is moved. 

MouseUp - The event sent by the GUI when the mouse button is 
depressed by the user. 

In order to track when PictureBox is being dragged and how far it has been dragged, the 
preferred embodiment utilizes the variables listed in Table 8, 



Table 8 - Internal Variables Used for Moving PictureBoxes 

SplitterDraggmg - A bit flag that is set to True when the user has 

Initialed dragging of the PictureBox. The bit flag 
is maintained True until the user stops dragging the 
PictureBox 

SplitterMousePos - Specifies the position of the mouse on the screen 

When dragging is initiated. 

MousePos - Specifies the position of the mouse on the screen 

when a mouse-related event is triggered by the GUI. 

When the PictureBox control receives the MouseDown event (the user has pressed the mouse 
button down while the mouse cursor is over the PictureBox), the SplitterDragging Hag is set to 
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True. This means that the user has initiated a drag of the PictureBox control with the mouse. 
The SplitterMousePos variable is set to MousePos. 

When the mouse is moved, the PictureBox control receives the MouseMove event. When this 
5 event is received, if SplitterDragging is True, the preferred embodiment knows that the user has 
moved the mouse while holding the mouse button down over the PictureBox. In order to 
simulate a dragging movement of the PictureBox, the preferred embodiment calculates how far 
the PictureBox must be moved in order to correlate with how far the user has moved the mouse. 
This is done using the pseudo-code in Listing 1. Note that the distance to move is clamped to the 
10 same range as the SplitterPos Vertical and SplitterPosHorizontal settings. 



Listing 1 



If SplitterDragging Then 
15 MoveDistance PictureBox . Lef t + McusePos.X - Spilt terMousePos . X 

If MoveDistance > (TDAWidth * 0.7 5) Then 

MoveDistance = TDAWidth * 0.75 
Elself MoveDistance s (TDAWidth * 0.10) Then 
MoveDistance = TDAWidth * 0.10 
20 End If 

SplitterPosHonzontal = (PictureBox . Lef t / TDAWidth) * 100 
PictureBox . Lef t - MoveDistance 

ResizeForm ' Causes summary document information to be redisplayed. 
End If 



25 



If the MouseMove event is received while SplitterDragging is True, the positions and sizes of the 
controls on the TDA are recalculated by forcing a call to resize the Host window. Because the 
process of calculating the positions and sizes of the controls on the TDA are relatively non- 
complex, the user does not perceives jittering or other artifacts typically associated with complex 
30 operations. In addition, the user sees a visual difference in the amount of space taken up by the 
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image and text. The process of positioning and sizing the controls on the TDA will be explained 
in further detail later on in the description of the preferred embodiment. 

When the PictureBox control receives the N4ouseUp event (the user has depressed the mouse 
5 button while the mouse cursor is over the PictureBox). the SplitterDragging flag is set to False. 

The process just described of trapping the MouseDown, MouseMove* and MouseUp events to 
simulate dragging of the PictureBox is a process understood by anyone educated in the art. 
Hereafter we will refer to this as a dragging process. 

10 

Whenever the PictureBox control is dragged, the SplitterPosVertical and SplitterPosHorizontal 
settings are adjusted accordingly. For example, if the horizontal PictureBox is dragged to within 
20% of the left edge of the TDA. then a value of 20 is placed in the SplitterPosHorizontal setting. 

15 Figures 8 and 9 are two display screens of the preferred embodiment before and after the 
PictureBox 801 has been moved. It can be seen that the maximum percentage area 802 that the 
image is permitted to occupy has changed, and thus the image is now smaller than it was before. 

Figure 10 shows a display screen of the preferred embodiment where the image width 1001 
20 doesn't fill the horizontal space provided by the maximum percentage area 1002 setting. It can 
be seen that the text area expands to fill the area 1003 unused by the image. This illustrates that 
the setting is a maximum percentage area that the image is permitted to occupy, not a specific 
defined percentage area that the image will occupy. 
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Calculation of Control Positions and Sizes 
There are three cases in which the position and size of the controls on the TDA should be 
recalculated. 

First, whenever a new document is loaded the positions and sizes must be recalculated. This is 
because the image width and height parameters may be different from document to document. 
Figures 4 and 6 show display screens of the preferred embodiment displaying two different 
documents, each document having a unique image size. Note that the TDA size is the same for 
each display screen. The orientation of the image in relation to the text is different for each 
document, thus showing how the preferred embodiment made a different decision because of 
different image sizes. 

Second, when the TDA size has changed the positions and sizes must be recalculated because the 
preferred embodiment may find a more optimal orientation and size for the image in relation to 
the text. Figures 11 and 12 show display screens of the preferred embodiment with two different 
TDA sizes, Figure 1 1 showing the preferred embodiment with a TDA that is wide and small, and 
Figure 12 showing a TDA that is tail. These figures illustrate how the preferred embodiment 
may make a different decision on image orientation based on TDA size parameters. 

Third, when the usee specified settings have been changed, the positions and sizes must be 
recalculated because the user-specified settings directly effect the amount of space the image is 
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allowed to cover, as well as ihe orienuuion of the image in relation to the text. TDA settings will 
be described in more detail later in this description. 

The general process for positioning and sizing the controls is shown in the flowchart in Figure 
5 13. 

Step 1301 determines the width and height of the TDA. This should not be confused with 
Panel's Width and Height Properties. The Panel control has a slight 3D edge that needs to be 
compensated for in the calculation of the TDA, which can be performed using simple formulas. 

10 

Step 1302 calculates Gear's size and orientation with relation to AUText. This process is 
illustrated in the flowchart contained in Figure 14 and will be described in more detail later on in 
this description. 

15 The specific purpose of step 1302 is to calculate the variables ImageHeight. ImageWidth, and 
ImageOrientation. The use of these variables is described in Table 9. 



Table 9 - Internal Variables Used for Calculating Control Positions 

20 ImageOrientation - The position cf the image in relation to the text. 

This is a mutually exclusive setting with the value 
being one of the three previously described constant 
values Drawir.gPositionAuto, DrawmgPositionAbove , 
and DrawingPosit lonLef t . 



25 



30 



ImageHeight - The final height for Gear. 

ImageWidth - The final width for Gear, 

MaxWidth - The maximum v:idth the image is allowed to occupy m 
the TDA. This does not mean that the final image 
width will be MaxWidth, but only that the final 
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image width cannot be more than MaxWidth. 

MaxHeight - The maximum height the image is allowed to occupy m 
the 7 DA . This does not mean that the final image 
heiqht will bt? MaxHeight , but only that the final 
imaqe height cannot be more than MaxHeight. 

Step 1303 sots the position and size of TabPro. The TabPro position and size are set according 
to Table 10. This serves the purpose of sizing TabPro such that it encapsulates the entire TDA, 
It is important to note that TabPro is encapsulated by Panel (it is a child of Panel). However, 
even though TabPro is expanded to fill the entire TDA, it does not encapsulate any other controls 
(e.g., Gear, AIlText, etc). 



Table 10 - Position and Size of TabPro 

50 
50 

Step 1304 sets the position and size of AHText. The position and size of AHText is dependent on 
the value of the ImageOrientation variable. If it is determined that the image should be oriented 
above the text, the AHText position and size are set according to Table 11. If it is determined 
that the image should be oriented to the left of the text, the AHText position and size are set 
according to Table 12. 



TabPro. Lert 
TabPro. Top 
TabPro. Width; 
TabPro. Height 



= t: .-width - 

- TLAHeight 



Table 1 1 - Position and Size of AIlText for Top Orientation 

AHText. Left - DocurnentEdgeWidth 

AIlText. Top = ImageHeight + DocurnentEdgeWidth 

AHText .Width = DceurnentWidth 40 

AHText .Height = DocumentHeight - ImageHeight + (DocurnentEdgeWidth * 2) 
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Table 12 - Position and Size of AllText for Left Orientation 

AllText. Left = ImageWidth + DocumentEdgeWidth 
AllText. Top = DocurnentEdnpWidth 
5 AllText .Width - ?C'?';i\entWi,ith - InugeWidth + DocumentEdgeWidth + 60 
AllText .Height = Document Height 

Slop 1305 sets the pus ii ion and size of Gear. As wiih AllText, the position and size of Gear are 
dependent on the value of the ImageOrientation variable. If it is determined that the image 
10 should be oriented above the text, the Gear position and size are set according to Table 13. If it 
is determined that the image should be oriented to the left of the text, the AllText position and 
size are set according to Table 14. It can be appreciated that Gear is always centered 
horizontally or vertically, depending on its orientation with respect to AllText. 



*5 Table 13 - Pes: t: on and Size cf Gear for Top Orientation 

Gear. Left - (DocumentWidth / 2) - {Gear. Width / 2) 

Gear. Top = Document EdgeWidth 

Gear. Width = ImageWidth 

20 Gear. Height = ImageHeight 



T able 14 - Position and Size of Gear for Left Orientation 

25 Gear. Left = DocumentEdgeWidth 

Gear. Top - (DocumentHeight / 2) - (Gear. Height / 2) 

Gear. Width = ImageWidth 

Gear. Height = Irr.ageHeight 



30 Step 1306 sets the position of the two instances of PictureBox. The visibility of each PictureBox 
is determined by the ImageOrientation variable. To help avoid confusion to the user, the 
preferred embodiment only allows the user to adjust one PictureBox at a time. If the image is 
oriented to the top of the text, then the vertical PictureBox is made visible and the horizontal 
made non-visible. If the image is orientated to the left of the text, then the horizontal PictureBox 

35 is made visible and the vertical made non-visible. The positions of each PictureBox are set 
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according lo Table 15. Note that only the Left Property is set for the vertical PictureBox, and 
only the Top Property is set for the horizontal PictureBox. 



Table 15 - Pr-in,:n and of ?:oti:: -xes 

5 

PictureBox . Left = DocumentWidth * DocSplitterPosVert * 0*01 
PictureBox .Top * DocumentHeight * DocSpiitterPosHonz * 0.01 

It is noted that the screen display layout for the text and image may differ from the printer 
10 output. Preferably, a separate set of print preferences is provided to define a text font, layout, 
image size, and other properties of a printed record. These preferences may also be persistently 
stored. According to a preferred embodiment, an intelligent layout feature ensures that most 
records fit on a single printed page. 

is Calculation of Image Size 

The positioning of the Gear, AUText. and PictureBox controls is dependent upon user selected 
TDA settings, the area of the TDA. and the document being displayed. 

When calculating the position and sizes of the Gear and AUText controls, the preferred 
20 embodiment takes into consideration the previously describes settings, specifically, the 
orientation of the image in relation to the text, and the maximum space the image is allowed to 
occupy. Figure 17 shows a flow chart illustrating the detailed steps needed to calculate the Gear 
and AUText control coverage areas. 
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The first step in calculating the Gear and AliText coverage areas is to load from memory or hard 
drive the user's orientation preference (1701) and the user's maximum image coverage 
percentages (1702). Methods for specifying this information have already been described. 

5 Once this information has been loaded, the preferred embodiment determines where the Gear 
should be located in relation to the AliText (1703). As previously described, the preferred 
embodiment allows the user to specify one of three orientations for the image relative to the text: 
to the left of, above, and automatically. Regardless of which orientation has been specified, the 
preferred embodiment utilizes several variables that are set to values that correspond with the 
10 orientation specified. These variables are shown in Table 9 

If the user has specified that the image be explicitly located to the left of the text in all cases 
(perhaps they have sized the Host window to be wide and short), then the preferred embodiment 
moves to step (1705). In this step the orientation variables are set to the values shown in Table 
15 10. 

If the user has specified that the image be explicitly located above the text in all cases (perhaps 
they have sized the Host window to be narrow and tall), then the preferred embodiment moves to 
step (1706). In this step the orientation variables are set to the values shown in Table 11. The 
20 maximum width of the image is defined as being a percentage of the width of the TDA as 
specified by the position of the vertical carrot. The maximum height of the image is defined as 
being the height of the TDA because it will be located to the left of the text and thus is allowed 
to fit as much of the vertical area as is available. 



Kovanen et ah 



-36- 



( 



However, if the user has specified thai the image be orientated relative to the text automatically, 
then the preferred embodiment moves to step (1704) to calculate an optimal orientation for the 
image. An optimal orientation is defined as being the preferred orientation (above or to the left 
of the text) that would allow the user to see the most information. The maximum width of the 
image is defined as being the width of the TDA because it will be located above the text and thus 
is allowed to fit as much of the horizontal area as is available. The maximum height is defined 
as being a percentage of the height of the TDA as specified by the position of the horizontal 
carrot. 

Whether the user has specified that the image be orientated above or to the left of the text, it is 
important to remember that the MaxWidth and MaxHeight values are not necessarily final values 
for the image. They are values representing the maximum area thai the image is allowed to 
cover. In practice, the image will cover much less area. 

If the user has specified they want auto-orientation, then the preferred embodiment must 
calculate whether either left or top orientation would be preferable, based on image width and 
height, and total document summary coverage area width and height (1704). Applying a simple 
ratio calculation, as understood by those skilled in the art, accomplishes this. 

If the ratio of the image's width and height is greater than the ratio of the TDA's width and 
height, then the preferred embodiment moves onto the step of calculating the maximum image 
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coverage values needed to calculate the final image dimensions based on a top orientation 
(1706). The orientation variables will be set to the values shown in Table 10. 



Otherwise, the preferred embodiment moves onto the step of calculating the maximum image 
coverage values needed to calculate the final image dimensions based on a left orientation 
(1705). The orientation variables will be set to the values shown in Table 9, 



The pseudo-code for steps (1703), (1704). (1705). and (1706) is shown in Listing 2. 



Listing 2 

Sub SetOnentat icx\ (DravmgOr ler.tat ion, MaxWidth, MaxHeight) 
If ImagePosit ion ^ ImagePes 1 t lonlef t 

Set Left iDrawir.gOrientation, MaxWidth, MaxHeight) 
If ImagePosit ion = ImagePcs i t lonAbove 

SetAbove (DrawmgOrientat ion, MaxWidth, MaxHeight) 
If ImagePosi tion ^ IiuagePcsit lonAutp 

If DrawingWidth > DrawmgHeight * (TDAWidth / TDAHeight) Then 
SetAbove (Draw mgOrientat ion, MaxWidth, MaxHeight) 

SetLef t (DrawmgOrientdticn, XaxWidth, MaxHeight) 
End If 
End If 
End Sub 

Sub Set Left (DrawmgOr mentation, MaxWidth, MaxHeight) 
DrawmgOrientat ion = DrawmgPosit lonLef t 
MaxWidth - TDAWi-ith * (Spl it terPosVert ical * 0.01) 
MaxHeight = TDAHe:ght_ 
End Sub 

Sub SetAbove (DrawmgOrientat ion, MaxWidth, MaxHeight) 
DrawmgOrientat icn = DrawmgPosit lonAbove 
MaxWidth = TDAWidth 

MaxHeight - TDAHeight * { Split terPcsHorizontal * 0.01) 
End Sub 



Regardless of which of the three orientations the user has specified, once MaxWidth and 
MaxHeight have been specified, the preferred embodiment then calculates the final image 
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dimensions (1707). This calculation is based on the need to fit the image into the coverage area 
available to the image as specified in the MaxWidth and MaxHeight variables. This allows the 
preferred embodiment to force the image to fit within the specified image coverage area without 
exceeding either the bounds of the user specified maximum percentage, nor the bounds of the 
5 TDA itself. 



Listing 3 shows the pseudo-code for calculating the final image area dimensions. Once the final 
image dimensions have been determined, they are stored in memory for use when it becomes 
necessary to draw the image and text onto the form or dialog. 

10 

Listing 3 

Width = ImageWidth / MaxWidth 
Height = ImageHeight / MaxHeiaht 

15 

If (ImageWidth / Height) <» MaxWidth Then 

Divisor = Width. 
Else 

Divisor - Heiaht 

20 

AreaWidth = Width / Divisor 
AreaHeight » Height / Divisor 



The AreaWidth and AreaHeight values hold the final values that will later be assigned to the 
25 Gear's Height and Width Properties, respectively. The process of determining whether or not the 
preferred embodiment will need to use these values will be discussed in further detail herein- 
below. 



When the Host starts, the Visible property of the Gear, AilText, and PictureBox controls is set to 
30 False. This provides the user with a visual appearance that there is no document loaded. 
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Section Headings and Tabs 
The preferred embodiment recognizes the record type and uses it to generate section headings 
and tabs. As the document text is loaded into the AllText control, each new record type that 
becomes available is added to the AllText as a heading and to the TabPro. Listing 4 shows the 
5 pseudo code used for this operation. 



Listing 4 

LoadText 
10 PrevRecordType = Null 
For Each Record 

If RecordType ^> PrevRecordType Then 
AddHeadmg RecordType 
PrevRecordType = RecordType 
15 AddText RecordText 

AddHeadmg RecordType 

TabPro. Tab = Sectionlndex 
TabPro. TabTag = Sectionlndex 
20 TabPro. TabState = TabEnable 

SectionRange (Sectionlndex) = AllText .CurPar=09 
AllText .SelLength * 1 
AllText. NTag = Sectionlndex 
Sectionlndex = Sectionlndex * 1=09 

25 

In this operation, it is important to note that there will exist one tab on the TabPro for each 
section that is loaded. 



The variable Sectionlndex keeps track of which section is currently being loaded. As the 
30 sections are loaded into the AllText control, the particular associated Tab of the TabPro is 
displayed and updated with the needed information about the current section. 



The SectionRange variable is set to the current cursor location in the AllText control as it is 
being loaded, and the NTag Property of the particular tab of the TabPro is set to the current 
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Sectionlndex. This allows the preferred embodiment to utilize this information at a later time to 
synchronize the tabs with the displayed text. 

Once the document has been loaded and displayed, the user can use the tabs to easily locate a 
5 particular section of text they want to view. Figures 17 and 18 show display screens of the 
preferred embodiment while viewing two different sections of text. 

Likewise, if the user decides to scroll the text using the scrollbar natively supplied by the 
AHText, as the user scrolls through the document sections, the corresponding tab will 
10 automatically be highlighted. This provides the user with a visual indication of what section they 
are in. The implementation details of this functionality with regard to the preferred embodiment 
will be explained hereafter. 

If the user clicks on a section tab, the preferred embodiment must automatically scroll the text in 
15 the AIIText to the corresponding section. This is done by trapping the TabPageShown event of 
the TabPro control. Figure 15 is a flow chart that illustrates this process, and listing 5 shows the 
code used to accomplish this in the preferred embodiment. 
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Listing 5 

Sub TabFro_TabPage3hown fActiveTab As Integer, ActivePage As Integer) 
Dim X As Long 
5 Dim Y As L<~ng 

Dim Result As Lcr.g 

If Sect icnScrolIUrdate Then 
Sect :or«Sc rol ICroa te False 
10 Exit Sub 

End If 

AllText .WnteProteet - A T X _JP R OT E CT_£ C R E E N 
AllText . Solent = Fals*- 
15 AllText .SialStart = r > 

TabPro.Tab - Active Tan 

Result = Fmd_NTag {AllText , Vai (TabPro .TabTag) , 1) 

Result = ATX_CurTcXY (AllText , AllText ♦ CurPar , AllText . CurChar , X, Y) 

20 

AllText . Select = 0 
AllText .ScrcllVei t - Y 

AllText .WnteProtect = A7X_PP0TECT_CHANGES 
End Sub 

25 

The preferred embodiment must first detect a tab selection event (1501). The paragraph 
corresponding to the selected tab is then determined (1502). The AllText control then updates 
the topmost paragraph to that which corresponds to the tab selection (1503). 



30 If the user scrolls using the scrollbar inherently provided by the AllText control, then the 
preferred embodiment must select the tab that corresponds with the section that is currently 
visible on the display. Figure 16 is a flow chart that illustrates this process, and Listing 6 
provides the code used in the preferred embodiment to accomplish this task. 
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Listing 6 

Sub AllText_AtxYSoxoiiClick tScrcllVert As Long) 
Dim Index As Integer 

Dim X As Long 
Dim Y As Long 
Tin, XI As Long 
Dim Yl As Long 

Dim Result As Integer 
Dim Paragraph As Long 
Dim C As Integer 

15 Dim Check As Integer 

Dim Continue As Integer 

Y s ScrollVert 

Result - ATX_XYToCur 'AllText , X, Y, Paragraph, C) 
20 Result * ATXjIurToXY(AllText , Paragraph, C, XI, Yl ) 

O For Index = Q Tc (Sect lonCour.t - \) 

!l q If (Paragraph >= Sect lonRange ( Index ) ) And _ 

f=n (Paragraph ^ Sec t lonRange ( Index i- 1)1 Then 

Jk25 If Sect lonRcmge [ Index -r 1 ) « 999 Then 

Continue = True 

For Check - (Index t 1; Tc Sect icr.Ccunt 
If Sect .cnRanye (Check) <> 999 Then 

If Paragraph >= Sect lonRange (Check) Then 
^30 Continue = False 

* End If 

M Exit For 

Q End If 

M Next 

CO 35 El:3e 

Continue - True 
End If 
If Continue Then 
I f Index = 0 Then 
40 ScrollTab 0 

Else 

ScrollTab Index 
End If 
Exit Sub 
45 . End If 

End If 
Next 
End Sub 

50 Sub ScrollTab (Index As Integer) 

If TabPro. Act lveTab <> Index Then 
SectionScrcliUpdate = True 
TabPro. Act lveTab = Index 
End If 
55 End Sub 



a 

'"'•4 



u 
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First, the preferred embodiment must determine which paragraph of AHText is the topmost 
visible (1601). The AHText control provides an interface fordoing this. 

Second, the preferred embodiment must iterate through each SectionRange to determine if the 
current paragraph falls within that range (1602). The SectionRange values were assigned during 
the document text loading phase and is described above. 

Once it is determined in which SectionRange the current paragraph falls, the preferred 
embodiment then uses the associated Sectionlndex to display the correct tab (1603). 

Select and Exclude Feature 
Another feature of the preferred embodiment is a document characterization input, in the form of 
a button bar 417, 418, (which may also have hot-key equivalents). In the preferred embodiment, 
a list of documents 41 1 meeting certain user-defined exclusionary criteria is provided in the left- 
hand pane of the display. These criteria (not shown in the Figures) include, for example, patent 
classification, application or issuance date. Boolean text search criteria, or the like. In the case of 
patent documents, the pane provides a listing of each document including patent number and 
title. To the left of the patent number, is a column 419 showing an indicia, such as a green check 
mark or red cross mark. These indicia correspond, for example, to a check box 417 for "select" 
and a check box 418 for "exclude", respectively. The default is "undecided" (no indicia), which 
may have its own check box. or be controlled based on the absence of other active check boxes. 
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It is understood that the criteria need not be "select" or "exclude", and may in fact be other 
predefined or user defined criteria, as a means for segregating the document list during review by 
the user. 

This segregation would serve as a means of "binning" the patents into categories that are 
meaningful to the user. For example, categories might be arbitrarily established for patents to 
order, patents held by competitors, patents that are marginally interesting, and patents owned or 
licensed by the inventor. 

Further, the user may seek to categorize the patents into various mutually exclusive or 
overlapping relevant topics. Thus, in this case, the user may be provided with a user defined 
categorization tool, which may also have a set of rules associated with it. These categories may 
each be represented by an iconic button on a button bar. for ease of selection. 

Once the patents have been selected or excluded (or binned.) the bins can be combined and 
manipulated using Boolean logic. A union of bins would be obtained by combining the patents in 
two or more bins. An intersection would be possible by logically AND-ing the bins (looking only 
for duplicates) in the event that a patent could be in more than one bin at a time. New bins 
could thereby be created from existing ones, or patents could be added to existing bins 
accordingly. For example, the bottom of the preferred display screen shown in Fig. 20 provides 
individually selectable display options 414. 415, 416 for the various categories of patents, 
including the excluded, selected, and undecided, respectively. 
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The process for performing Boolean logic on groups of items that are uniquely identified such as 
by a patent number is well known in the art of patent searching and programming, 

5 A set of functions may then be applied based on the user-selected criteria, such as Print, Order 
(hardcopy). Save (as a list for later review or manipulation), or other function, by the Host, 

In the case of a patent document review, the predefined select, exclude and undecided criteria are 
preferred. 

10 

The foregoing description of the preferred embodiment of the invention has been presented for 
purposes of illustration and description and is not intended to be exhaustive or to limit the 
invention to the precise forms disclosed, since many modifications and variations are possible in 
light of the above teachings. Some modifications have been described in the specifications, and 
15 others may occur to those skilled in the art to which the invention pertains. Therefore, the scope 
of the invention is to be defined solely by the claims that follow. 
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CLAIMS 

What is claimed is: 

1. A method for presenting document records to a user through a display interface, 
comprising the steps of: 

(a) selecting a data file from a plurality of data files; 

(b) analyzing the data file for the presence of data of a first type and a second type; 

(c) processing data of the first type through a first applet and data of the second type 
through a second applet; 

(d) merging and formatting the processed first and second data with a host 
application; 

(e) displaying the merged and formatted processed first and second data; and 

(f) managing a plurality of data files with the host application. 

2. A data file format comprising: 

a header portion containing an index portion; 

a first data type located near a terminus of the data file at a starting location referenced by 
the index portion; and 

a second data type located between the header and the first data type, having an end of 
file marker at its terminus. 

3. A method of processing a data file having two different data types, comprising the 
steps of: 
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(a) processing the data file with a first applet, adapted for reading data of a first data 
type, to extract data of the first data type; 

(b) processing the data file with a second applet, adapted for reading data of a second 
data type, to extract data of the second data type, 

5 wherein the data file includes an index portion in a header pointing to the first data type, and the 
second data type resides between the header and the first data type, having an end of file marker 
at a terminus thereof, 

4. A method for manipulating a record list, in which each record on the list may be 
10 individually selected, comprising providing at least two distinct categorization inputs from the 
user, providing an indicia in the record list to indicate a respective record classification, and 
providing means for selectively processing the records according to a respective classification 
thereof. 



Kovanen et al. 



-48- 



ABSTRACT 

A system and method for presenting document records to a user through a display 
interface, comprising means for processing data of the first type through a first applet and data of 
the second type through a second applet and separately extracting data of the two different types 
using the separate applets. The user interface provides means for selecting a data file from a 
plurality of data files, displaying the merged and formatted processed first and second data, and 
managing a plurality of data files with the host application. Each record on the list may be 
individually selected, comprising providing at least two distinct categorization inputs from the 
user, providing an indicia in the record list to indicate a respective record classification, and 
providing means for selectively processing the records according to a respective classification 
thereof. The data file employs a standard image format file with an embedded index pointer to 
segregate two data types. A first data type, preferably an image, is referenced by the index 
pointer and is located near the terminus of the file. A second data type, for example text, appears 
immediately after the file header which includes the index pointer, and preferably terminates 
with an end of file marker. Thus, the single file may be read by both a standard image file 
reader, and a standard text reader, without parsing or segregation. The two data types are 
preferably text and image data, and the data file is preferably a tagged image format file (TIFF) 
file with Group-4 image compression. 
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Computer with an 
Improved disk drive 
mounting assembly 



|^ computer, or other similar type off 
electronic device including a chassis j 
land one or more disk drives mounted! 
Jin the chassis. A mounting bracket for] 
.receiving a disk drive is mounted to the! 
'computer chassis and is precisely| 
llocated relative to a wall of the| 
.chassis. A mounting plate for receiving! 
'another disk drive is mounted relative! 
to the bracket and to the chassis and] 
. ■*» *is also precisely located relative to a| 
} wall of the chassis and to the bracket 
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Power supply mounting assembly for 
electronic equipment 

mounting assembly for mounting a component in electronic! 
equipment, such as a computer system, which includes an! 
enclosure and a mounting bracket pivotally mounted to thej 
enclosure. One or more retaining members are disposed on the] 
bracket for engaging the component to retain the component in the* 
bracket in abutting relationship. The bracket, and therefore the] 
component, are connected to the enclosure so that they can be] 
pivoted between a position in which the component is mounted in i 
the enclosure and a position in which it extends out of the* 
enclosure. In the mounted position, the bracket forms a portion of j 
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Multimedia carousel 
&\ J I for video conferencing 
;;;}... and multimedia 
• I presentation ; 
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applications 
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A multimedia carousel for use in 
video conferencing and multimedia 
j}^20 (presentation applications is 
^ 'disclosed. The multimedia carousel 
jincludes a cube-shaped media unit 
'rotatably disposed on a stationary 
jbase. Each of the four outwardly 
'facing sides of tine media unit is 
{equipped with an active color matrix 
'display, a voice-activated charge 
icoupled device (TCD*) camera 
and a microphone. A single high 
{fidelity speaker is disposed on the a 
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Multimedia carousel for video 
conferencing and multimedia 
presentation applications 

A multimedia carousel for use in videos 
conferencing and multimedia presentation^ 
applications is disclosed, The multimedia^ 
carousel includes a cube-shaped media unit!! 
rotatably disposed on a stationary base. Each of^ 
the four outwardly facing sides of the media unit is^ 
equipped with an active color matrix display, a: 
voice-activated charge coupled device CCCD")^ 
camera and a microphone. A single high fidelity 
speaker is disposed on the top side surface of thegjj 
cube for producing high quality audio output. ;: .. $jk 

l 
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\ Multimedia 
camuset for video 
conferencing and 
/ <^mui1Jmedia 
(^presentation 
applications 

Y~ — \O02- 
|A multimedia carousel fori 
iUse ii video conferencing! 
and multimedia presentation! 
applications is disclosed. Thej 
multimedia carousel includes! 
a curie-shaped media unitf 
rotatably disposed on a| 
istationbry base, Each of thei 
Tour outwardly facing sides of | 
toe rrledia unit is equipped! 
with an active color matrixs 
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Power supply mounting assembly for 
electronic equipment 

A mounting assembly for mounting a component in electronic 
equipment, such as a computer system, which includes an| 
enclosure and a mounting bracket pivotaliy mounted to the 
enclosure. One or more retaining members are disposed on the 
bracket for engaging the component to retain the component in the 
bracket in abutting relationship. The bracket, and therefore the 
component, are connected to the enclosure so that they can be 
pivoted between a position in which the component is mounted in 
the enclosure and a position in which it extends out of the 
enclosure. In the mounted position, the bracket forms a portion off 
one or more walls of the enclosure 
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As the below named inventors, I/We hereby declare that: 

My/Our name(s), residence(s), post office address(es) and citizenship(s) is/are as 
stated below next to my/our name(s). 

If one name appears below, I am the sole inventor of the subject matter sought to 

be patented. 

If two or more names appear below, we are joint inventors of the subject matter 
sought to be patented. 

I/We believe I/We am/are the original; and first inventor(s) of the subject matter 
which is claimed and for which a patent is sought on the invention entitled 

ENHANCED HUMAN COMPUTER USER INTERFACE SYSTEM FOR 
SEARCHING AND BROWSING DOCUMENTS 

the specification of which 

[x] is attached hereto. 

[ ] was filed on as application Serial No. . 

I/We hereby state that I/We reviewed and understand the contents of the above- 
identified specification, including the claims, as amended by any amendment referred to above. 

I /We acknowledge the duty to disclose information which is material to the 
examination of this application in accordance with Title 37, Code of Federal Regulations, 
Section 1.56(a). 

I/We also acknowledge the duty to disclose information which is material to the 
examination of this application in accordance with Title 37, Code of Federal Regulations, 
Section 1.63(d), which occurred between the filing date of the prior application and the filing 
date of the continuation-in-part application, if this is a continuation-in-part application. 

I/We hereby claim foreign priority benefits under Title 35, United States Code, 
Section 1 19 of any foreign application(s) for the patent or inventor's certificate listed below and 
have also identified below any foreign application for patent or inventor's certificate having a 
filing date before that of the application on which priority is claimed: 



Prior Foreign Application: Application No. 

filed 

Priority Claimed: Yes No 



I/We hereby claim the benefit under Title 35, United States Code, Section 120 of 
any United States application(s) listed below and, insofar as the subject matter of each of the 
claims of this application is not disclosed in the prior United States application in the manner 
provided by the first paragraph of Title 35, United States Code, Section 1 12, 1 acknowledge the 
duty to disclose material information as defined in Title 37, Code of Federal Regulations, Section 
1.56(a) which occurred between the filing date of the prior application and the national or PCT 
international filing date of this application: 



Application Serial No. Filing Date {v ^ Qd jMI% M 



Application Serial No. Filing Date (patented J^tafc^ 

I/We hereby declare that all statements made herein of my/our own knowledge are 
true and that all statements made on information and belief are believed to be true; and further 
that these statements were made with the knowledge that willful false statements and the like so 
made are punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the 
United States Code and that such willful false statements may jeopardize the validity of the 
application or any patent issued thereon. 

I/We hereby appoint the following attorneys and/or agents to represent me with 
respect to the above identified U.S. Patent Application, and to prosecute any continuations, 
continuations-in-part, reissue applications and/or reeaxaminations with respect to these 
applications and to transact all business in the Patent and Trademark Office connected therewith, 
and hereby expressly revoke all prior powers, whatever they may be, heretofore had herein: 

Karl F. Milde, Jr., Reg. No. 24, 822; Steven M. Hoffberg, Reg. No. 33,51 1 and 
Kenneth E. Macklin, Reg. No. 20,875, all of 10 Bank Street, Suite 460, White Plains, 
New York 10606, my/our attorneys with full power of substitution and revocation. 



Please address all telephone calls to Steven M. Hoffberg, Esq. at telephone No. (914) 949-3100. 
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